1. Blob Data Stores
Blobs
are files that can be stored in Windows Azure. What is interesting
about blobs is that they can be easily accessed through REST, there is
no limit to the number of blobs that can be created, and each blob can
contain as much as 50GB of data. As a result, blobs can be used as a
backup and transfer mechanism between consumers.
A system can dump SQL Azure
tables to files using the Bulk Copy Program (BCP), possibly compressing
and/or encrypting the files beforehand, and store the blobs in Windows
Azure.
2. Edge Data Caching
The chapter briefly
mentioned caching earlier, but you should remember that caching may
yield the most important performance gains in your application design.
You can cache relatively static tables in memory, save them as blobs
(or a form of in-memory storage) so that other caching systems use the
same cache, and create a mechanism to refresh your data cache using
queues in Azure.
Figure 1
shows an example of a design that creates a shared cache updated by two
ERP systems. Each ERP systems uses the transparent branching pattern to
update shared records in a SQL Azure database. At this point, however,
the edge caches aren't aware of the change in data. At a specific
interval (every 10 minutes, for example) a worker process in Windows
Azure picks up the changes and stores them in blobs. The worker may
decide to apply logic to the data and resolve conflicts, if any. Blobs
are then created (or replaced) with the latest cache information that
should be loaded. The edge cache refreshes its internal data by loading
the blobs at specific intervals (every 5 minutes, for example) and
replaces its internal content with the latest cache. If all edge caches
are configured to run against a public atomic clock, all the caches are
updated virtually at the same time.
3. Data Encryption
You can encrypt your data in two
environments: onsite or in Windows Azure using a service. SQL Azure, as
previously mentioned, doesn't support encryption at this time (although
hashing is supported). If you need to encrypt Social Security numbers
or phone numbers, you should consider where encryption makes sense.
Generally speaking, unless
your application runs in a public environment where your private keys
can be at risk, you should consider encrypting onsite before the data
goes over the Internet. But if you need a way to decrypt in Windows
Azure, or you need to encrypt and decrypt data across consumers that
don't share keys, you probably need to encrypt your data in Windows
Azure before storing it in SQL Azure.
